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REMOIELY PILOTED VEHICLE: APPLICATION OP THE 


GENERAL RELIABILITY ANALYSIS SIMULATION PROGRAM 


William L* Andre and J. Bradley Morris 


Ames Research Center 
ano 

Aeromechanics Laboratory 
U.S. Army R&T Laboratories (AVRADCOM) 


SUMMARY 


This Is a consolidation of the preliminary work done in the application 
of a General Reliability Analysis Simulation Program (GRASP) for the Lockheed 
Remotely Piloted Vehicle (RPV) system, being developed for the United States 
Army. 


The model simulates the field operation of the RPV syst«n. By using 
individual component reliabilities, the overall reliability of the RPV system 
is determined. The results of the simulations are given in operational days. 
The model represented is only a basis from which more detailed work could 
progress . 

The RPV system in this model is based on preliminary specifications and 
estimated values. The scope of this report demonstrates the use of GRASP from 
basic system definition, to model input, and to model verification. 


INTRODUCTION 


This report is a consolidation of the preliminary work done in the appli- 
cation of a General Reliability Analysis Simulation Program (GRASP) for the 
Lockheed Remotely Piloted Vehicle (RPV) system, being developed for the United 
States Army. 

This paper demonstrates the process used to create the RPV model, to 
change the model into the RPV data set, to validate the RPV model/data set, 
and the steps necessary to interpret the output. The results of the GRASP 
simulation are expressed in successful operational days. A successful opera- 
tional day is defined as the completion of three D-hr mission flights in a 
12-hr period. Each simulation begins with five new air vehicles and all 
ground equipment in operational status. 

The conclusion of the report emphasises the versatility of using GRASP, 
and the status of the RPV data sets. 


ABBRSVAITIONS 


ADT air data tarminal (part of MICN8 conminicationa packaga) 

AF air frama 

ARA air refaranca aaaambly 

AV air vahlcle 

AVIM air vahlcla Intarmadlata malntananca 

AVO air vehlcla operator 

AVOC air vahlcle operator conaola 

AVUM air vehicle unit maintenance 

EPS electrical power system 

FCEP flight control eleccronlcs package 

FLT flight 

GCS ground control station 

GCSIU GCS interfacing uni! 

GEN generator 

GRASP generalized reliability analysis simulation program 
GSE ground support equipment 

IR infrared (landing system) 

LA launcher assembly 

LMSC Lockheed Missiles and Space Company 

LRU line-replaceable units 

MAIM main GCS computer 

MC mission commander 

MCO mission commander operator 

MCOC mission commander operator console 

MICNS modular integrated control navigation system 

MP mission payload 

MPC mission payload operator console 

MPO mission payload operator 

MPS mission payload subsystem 

MS maintenance shelter 

MTBF mean time before failure 

NAV navigation 

NPV navigation display unit 

PROP propulsion assembly 

REC recovery subsystem 

RGT remote ground terminal 

RPV remotely piloted vehicle 

TTF time to fail 

TTR time to repair 

GRASP 11 COMPUTER PROGRAM REVIEW 

GRASP II (Version II) is a Fortran-based computer program which can simu- 
late a reliability-based system operation consisting of time and cost. GRASP 
is a method by which a system can be represented by certain parameters and 
logical relationships, and be shown graphically as a network diagram present- 
ing the reliability configuration of that system. 
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In order for a model to be developed* certain bui:>dlng blocka muat ba 
underatood. GRASP network diagraaning la based on two basic elemente: nodes 

and arcs. Nodes are events in the system* such as a failure of a component* 
end of a repair* or completion of any other type of activity. Nodes are 
denoted by circles in which N1 is the number of pulaea needed to release the 
node the first time and N2 is the number of pulses needed to release the 
node at subsequent times. Arcs* or branches* represent time-consuming activ- 
ities* such as time-to-fail (TTF)* tlme-to-repair (TTR)* or any event prece- 
dence relationship in the system. Event precedence relationships have no 
duration, that is* they occur instantaneously. (See figure 1 for exanqiles of 
nodes and arcs.) 

This is a basic look at the GRASP network diagram. Further information 
can be obtained from the GRASP Users Manual, and it is recommended that the 
reader review and become familiar with GRASP if a more detailed dlsctission is 
required. 


NODE 



ARC 




Figure 1.- Arc and node diagram. 


COMPOSITION OF THE LOCKHEED RPV SYSTEM 


The Lockheed RPV system consists of several components. These components 
divide the RPV system into key factors from which a network model can be made. 
In the following discussion* the overall mission function Is first explained 
and then the individual components are described as they relate to the system. 
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The RPV systeD. as addressed In this report, is a cosd>lnation of hardware 
and nission function. The hardware consists of mobile ground units used to 
support the air vehicles (AV) and the five AV's used for mission function. 

The mission function consists of spotting and designating targets. The 
steps In this process Include the prelaunch check (making sure all systems are 
working); the cllmb-out; the outbound flight; the mission stage where targets 
are found and Identified; the Inbound flight, which Is similar to the outbound 
flight; and the recovery cf the AV. The mission occurs between the outbound 
and Inbound flight segments. 

The hardware consists of seven mobile ground units: 

1. Launcher truck 

2. GCS (Ground Control Station) 

3. Recovery truck 

4. NS (Maintenance Shelter) 

5. Crane truck (truck carries two AV's) 

6. AV truck (truck carries three AV's) 

7. Pickup truck 

Trailers for transporting the Remote Ground Terminal (RGT) and two generators 
are also required. 

The GCS controls the AV while the AV is in flight. It can also perform 
the checkout during prelaunch and monitor tests during a mission flight. The 
MS (Maintenance Shelter) is a field workshop for repairing the AV's, GCS, RGT, 
generators, launcher, and recovery truck. 

The following description of the RPV system provides a working knowledge 
of the basic system characteristics as they relate to this report; it is 
public information, having been published in Aviation Week and Space Technol- 
ogy (vol. 112, no. 2, Jan. 7, 1980, pp. 54-63) . 

The major areas of reliability concern are between stages C to F (fig. 2), 
where C to D to E is system checkout, E to F is AV flight and mission opera- 
tions, and F to "or" is the recovery of the AV. Although factors of emplace- 
ment leading up to state C can be modeled, a limit must be placed on the size 
of the RPV system being modeled by GRASP; therefore, the system of emplacement 
has been disregarded. 

An objective of the model analysis is to simulate the operational limits 
of a fielded RPV unit, that is, how many days can the system operate (success- 
fully) from a fresh start, where a successful day is defined as three success- 
ful mission flights being performed within a 12-hr period. Thus the RPV 
system baseline model revolves around prelaunch and flight of the AV's, 

The day begins with an AV on the launcher ready for its prelaunch check. 

If it is determined that the AV falls the prelaunch check, the prelaunch is 
aborted. The model will start a removal (time 15 min) of the bad AV from the 
launcher and replace it (in 15 min) with a good AV from the ready-pool. If 
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Figure 2.- Functional baseline 

















the GCS or any other ground equljment fella and cauaea the launch to be 
aborted, the model aborta and walta until the failed component la fixed. Upon 
repair the model beglna a new prelaunch check. 

The GKASP model cannot detect multiple fallurea at a alngle time. For 
example, If the GCS and a generator fall at the aame time, the GPASP aelecta 
the one that waa coded In flrat into the program and aelects that particular 
one aa the failed component. In any caae, thla la not a problem becauae the 
failure rates are low to start with. 

Using the above example, another assumption, based on low failure rates. 
Is that If the GCS and generator fall at the same time, they go Into repair 
at the same time. The modeled RPV system has only one Maintenance Shelter 
(MS) and multiple repairs are handled on a sequential priority basis. 

The key functional paths used In the model are diagrammed In figure 3, 
which shows how the AV's are used In the system. 



After being provided with some Initial assumptions, a meeting was held 
wherein more refined assumptions were Incorporated Into the model. Those 
assumptions are listed below: 

1. If GCS main computer falls during a mission, the mission Is aborted 
and Inbound and recovery paths are set up. Note that the recovery 
operates at lower values. 

2. The laser Is needed for the mission and Is only used during the out- 
bound flight for position updating. 
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3. The recovery stage of the mission flight can be successful with IR 
or MPS recovery systems. Note that only MPS is used when IR is down. 

4. If a subsystem goes dmm, it goes into repait without delay. 

(Exact! <3 ' AV, CCS, RGT, CSE, LA, Recovery.) The probab'llity of more 

than ' >e subsystem being down at the same time is low. 

5. Launcher and Recovery hardware will only fail in an active state. 

6. GSE refers explicitly to power generators. Note that the remote 
ground terminal has its own generators. 

7. Of the three different maintenance systems, each exhibits its own 
characteristics for isolation of problems. 

A chart was made up showing the reactions of the possible failed com- 
ponents during possible events. This provided a framework upon which the 

complete RPV system was composed into functional elements. A GRASP network 

diagram is constructed from table 1. This topic will be discussed in the 
next section. 


BUILDING OF THE GRASP NETWORK 


In the previous section the RPV system was broken down into functional 
elements. The idea was to represent these functional elements as nodes 
(events) and arcs (timed activities). The key hardware elements are the AV, 
GCS, RGT trailer, generators, launcher assembly truck, and recovery truck. 

For the reliability model and GRASP network model, the AV will be repre- 
sented by seven subsystems. 

1> MP: mission payload 

2. FCEP: flight control electronic package and flight sensor package 

3. ARA: air reference assembly 

4. ADT: air data terminal 

5. EPS: electrical power system 

6. AF: airframe 

7. PROP: propulsion assembly 

Certain assumptions that pertain to th'' AV are described next. It was 
assumed that failure during prelaunch of any of che AV subsystems (1 through 7) 
would cause the launch to be aborted. This is then followed by removal of the 
failed AV (15 miii) and its replacanent on the launcher with a good AV from the 
ready-pool. 

The AV subsystems were also modeled allov'ing for failure of the MP 
(mission payload) package during flight. This failure would result in the 
return of the AV with the proper sequencing time. Also, upon recovery of the 
AV with the failed MP, a reduced reliability of recovery occurs. Sequencing 
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TABU 1.- FAILURE MODES FOR SUBSYSTEMS 





Action 



Failure 








Launch 




1 



Pr a launch 

clinb-ojt 

Outbound 

Mission 

Inbound 

Reaourcas 

Two of three 
consolea* 

Repair 

recycle 

AV lost 

AV loot 

AV lost 

AV lost 

AV lost 

One of three 
consolea^ 

Repair 

recycle 

Recovery 

Inbound/ 

recovery 

Inbound/ 

recovery 

Recovery 

No effect 

Navigation 

display 

unit® 

Repair 

recycle 

Recovery 

Inbound/ 

recovery 

Inbound/ 

recovery 

No effect 

No effect 

Main 

computer® 

Repair 

recycle 

Recovery 

Inbound/ 

recovery 

Inbound/ 

recovery 

No effect 

Recovery 

degraded 

mode 

GCS I/U* 

Repair 

recycle 

AV lost 

AV lost 

AV lost 

AV lost 

AV lost 

Launcher 

hardware 

Repair 

recycle 

No effect 

No effect 

No effect 

No effect 

No effect 

Recovery 

hardware 

No effect 

No effect 

No effect 

No effect 

No effect 

AV lost 

GSE 

Repair 

recycle 

AV lost 

AV lost 

AV lost 

AV lost 

AV lost 

RGT® 

Repair 

recycle 

AV lost 

AV lost 

AV lost 

AV lost 

AV lost 

MPS/TV 

Repair 

recycle 

Recovery 

Inbound/ 

recovery 

Inbound/ 

recovery 

No effect 

IR only 

Laser 

Repair 

recycle 

Recovery 

Inbound/ 

recovery 

Inbound/ 

recovery 

No effect 

No effect 

FCEP 

Repair 

recycle 

AV lost 

AV lost 

AV lost 

AV lost 

AV lost 

\KA 

Repair 

recycle 

AV lost 

AV lost 

AV lost 

AV lost 

AV loot 

Propulsion 

Repair 

recycle 

AV lost 

AV lost 

AV lost 

AV lost: 

AV lost 

ADT 

Repair 

recycle 

AV lost 

AV lost 

AV lost 

AV lost 

AV lost 

IR 

Repair 

recycle 

No effect 

No effect 

No effect 

No effect 

MPS 

landing 


lO-nln delay to determine If equipment cannot be placed back into operational 
fitatua. 
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tlM r«J«ra to tho tin* noodod fow the return of en AV In the event of e iell- 
ure. If the AV le on cllab-out or outbound end a failure occure» then the AV 
la returned. The time that the model haa uaed to get the AV to the cllttb^out 
or outbound la eaauned amell. If the MP faila on the mlaaion pheee, then the 
model eterta an inbound flight upon detection of the failure. Thua the 2S^ln 
period for the Inbound flight la not negligible aa waa the case In the failure 
of the MP during climb-out or outbound flight. 

The modeling of the other hardware elamenta le not aa complicated aa that 
of the MP. The AV aubayateaa are grouped together. Aa atated before. If any 
of theae aubayatema fail during the prelaunch, the launch la then aborted and 
AV replacement procedurea are atarted. If the other Itema fall during flight 
(excluding MP) then the model will crash the AV at the time of failure and 
begin the launch of a new AV. 

Upon aucceasful lau*' .n of the AV, another AV from the AV ready-pool la 
placed on the launcher. This process Is done so that If the AV In the air 
falls and crashes, then the AV on the launcher la ready for Its prelaunch 
checkout. 

During the mission flight the AV is continually checked as two separate 
systems: (1) the misalon payload, and (2) items 2 through 7 above (p. 7). 

If any f these systems fail, the model will properly select the path for that 
failure to be recognized. 

The CCS has 10 major subsystems for its model. Of these 10, only 6 are 
necessary for nroper modeling: the three consoles, the CCS Interface Unit 

(lU), the navigation display, and the main computer. 

The omission of the communications equipment is Justified because there 
is adequate redundancy in that system and because the communications network 
does not directly affect the critical operation of either the RPV or AV. 

The AVO (air vehicle operator) console, MPO (mission payload operator) 
console, and the MCO (mission commander operator) console are assumed to 
operate in a somewhat redundant fashion. That Is, if one console falls then 
the AV can still be controlled (to a limited extent) and return of the AV is 
initiated. If two consoles fail, control of the AV cannot be maintained and 
the AV is lost. There is a 10-min tiuier that sets the limits for repair of 
the CCS and reestablishment of communications with the AV. These \0-min 
timers are not only for the consoles but also for other CCS subsystems in *..ie 
model. 


Cf the six components used to model the CCS there are only two failures 
that result in loss of the AV: a two-console failure (aa stated before) and 

less of the CCS interface unit compuCtr. 

a model component fails and is not sent Immediately to repair, a 
repair facility is designated for that component. (Note that this is based 
on low failure rates.) For the CCS model, GRASP generates only one set of 
failure data at the start of the simulation. When a CCS subsystem fails. 
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GftASP g«n«ratta a new nnan tlmn between fellure (MIBF) for that particular 
aubayatee only, unlike the AV model In idilch a new aet la derlwed for each 
flight at prelaunch. 

Xf the GCS doea go down and an AV ia loat, the model walta until the 6C8 
la b^.ck up (arc 141-142 value #31) before atarting a prelaunch check (node 6 
to atart pralaunch at node 2). Node 6 monltora the atatua of the from 
node 152. When node 6 releaaea then It la known that an AV la on the launcher 
and that the GCS la ready to do a prelaunch. 


VERIFICATION PROCESS 


Aa with any prograwt experience in debugging ie an easentlal element when 
input errors or logic errors surface. Both errors are difficult to correct, 
but finding the logic errors seems to be more challenging. GRASP has an 
option that is very useful in finding these logic errors. It la called the 
trace option, as specified on the first input card. The trace option gives 
the user a printout of the step-by-step pulse actions that occur In the model. 

After the model has been diagrammed, it must then be incoded in the 
proper order for input inro the GRASP program. The best process for checking 
the input is a node-by-node , arc-by-arc review. This proce.«3 is most effec- 
tively done by two persons: one to read the node from the network diagram 

and the other to check it off on the computer printout. Thi« process checks 
for input errors that may have occurred. 

Next, the trace option is mnployed to analyte tht <yutput and validate 
the pathway of the pulse. In valld«i>*'lng the model, errors surface es.aily anl 
can be Identified quickly. In one example, the trace option located a mis- 
placed arc, which was causing a pulse to split in two. After locating the 
proolem. It was soon corrected. The trace option, furthermore, follows the 
logic patten^ of the model, thus providing an easy way to check for logic 
errors . 


SAMPLE INTERPRETATION 


A total of 14 different model-system configurations were addressed, each 
evaluated on a nodal -observation basis. The frequency of a node's occurrence 
was recorded on a cumulative basis. Other Information was provided such aa 
minimum time ?f occurrence, maximum time of occurrence, and standard devia- 
tion. For our particular model, only the number of observations was Important. 
Other features could be Incorporated, but because of the simplistic nature of 
the model they were omitted. Thus the nimber of observations could be con- 
verted into the number of days the RPV system is operational. A sample run 
follows, which serves to demonstrate the method of interpretation. 
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Node 

Number of observations 

5 

27 

182 

23 

299 

50 


Number of observations (node 5) ■ 27 

Number of simulations * 100 

27/100 - 27% 


Nodes S and 182 show a system-failure situation, with the nodes Indicating the 
cause or source of failure. Node 5 was observed 27 times In 100 simulations. 
Indicating a 27-percent occurrence due to depletion of available air vehicles. 
Node 182 was observed 23 times. Indicating a 23-percent occurrence due to 
incomplete 3-hr missions in the 12-hr periods. Node 299 (Indicating success- 
ful missions) was observed 50 times In 100 simulations, showing 10 successful 
operational days without failure of the RPV system. 


RECOMMENDATIONS 


The system model discussed In this paper Is only a base from which more 
detailed work could progress. Significant improvements might Include: 

1. Adding cost to the model. Although not specified In this report, 
additional cost requirements and values could be assigned after preliminary 
research. 


2. Varying the mission time. This model uses a maximum time of 3 hr 
(plus 5 min prelaunch) to perform a mission scenario. A routine could be 
designed to vary the mission time between 1 hr and 3 hr. 

3. Modeling the subsystems past the line-replaceable units (LRU's) to 
the board level or part level. This would provide far greater accuracy in 
the function and operation of the system. 

4. Finding *^he average number of operational days. This model now 
determines the number of operational days until three successful flights cannot 
be completed within 12 hr. The model could be altered to determine, for 
example, that In 100 days, 80 are operational (l.e., produc'ng successful 
missions) and 20 are failures. 

At the conclusion of this project, additional features were requested 
from Lockheed, but there was no time to Implement them. However, Lockheed 
suggested changing the failure rate for the AV subsystem so that a percentage 
of the failures would cause the AV to crash. Figure 4 shows the present 
failure monitor features of the AV subsystem, and figure 5 shows the effects 
of ch inglng the features to accommodate a percentage of failures. 
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Th« RPV By«t«a In this nodnl It bnnnd on •peclflcntlons and •ttlnacnd 
values » and the reader should bear in alnd that corrections of data values or 
nodlflcatlons nay be necessary as time goes on. It should aleo be noted that 
the statue of the model presented In this report Is by no means indicative of 
the operational status of the RPV system under developnent at IMSC. 



Figure Current AV subsystem. 
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Figure 5.- Proposed modifications to AV subsystems. 
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A1»PEMD1X A 


NODE DIAfiBAMS 


lh« nod« diagrams are a pictorial analysis of the GRASP-RFV model. The 
mainline model consists of figures 6-9, Figures 10-13 show other system and 
support equipment. 



Figure 6.- Prelaunch, cIliri>ouC 





Figure 7.- Outbound, mission 
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Inbound, recovery. 





PUT AV 
BACK IN POOL 



Figure 9.*’ Recovery^ tlner. 





Figure 10.- AV eubeystea, ground equlpaent. 



QCS SUBSYSTEM 



1 


Figure 11.- CCS subsystem, ground equipswnt. 




AUXILIARY RECOVERY 
INBOUND 



28 
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Flgu.- 12.- Auxiliary recovery 
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Figure 13. Maintenance shelter plans 


APPENDIX B 


NODE-ARC DESCRIPTIONS 


This ••ction d«scribM th« nMnlnga for tho nodoa nd orco in tho nod* 
dlagrama. Tho ooctlon lo cocogorliod by nodo mnd>or with tho dooci Option of 
tho orco folloiflng. 


PRELAUNCH, aiMBOUT (Figure 6) 

Node Significance 

2 Indicates start of simulation, start of preflight /prelaunch chock 

Arc 2-11: begins prelaunch check 

Arc 2-81: checks the AV for starting new distribution 

3 Indicates abort required due to AV failure 

Arc 3-10: issues abort 

Arc 3-5: removes inoperative AV from launcher within a 

15-min period 

Distribution 1 , parameter 8 

4 Indicates new AV from pool placed on launcher 

Arc 4-6: requires 15-min replacement period 

Distribution 1, parameter 8 

Arc 4-S: removes one AV from ready-pool 

5 Indicates nimber of AV's used: N1 > 5, N2 ■ 5 (N2 indicates 

all AV's used; simulation over) 

6 Indicates si>rultaneous readiness of CCS and of AV on launcher 

Arc 6-2: both CCS and AV ready for prelaunrh check 

7 Indicates prelaunch check stopped due to ground component 
failure (GEN & RGT); IS performed but not 14 

Arc 7-178: ground equipment working 

8 Indicates ground equipment not working; waiting for repair 
(14) from arc 93-94 

Arc 8-8: pulse c -cl ng on l-roin 

Distribution 1, parameter 1; wait for repair 

178 Indicates whether prelaunch was aborted due to CCS failure 
Arc 178-9; CCS backup 

179 Indicates CCS still down In repair 

Arc 179-179: 1-min check — when CCS repaired, pulse transfers 
back to arc 178-9 
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Mod* 


flcaiie* 



9 Zndieatca Junction (n^aivor noda){ ready to bagiA pralameh 
Are 9-lOt updater err. '.o count aterta 
Arc 9-2 1 rapalra f;»n:'shad» atart pralaunch again 


10 Ittdieataa nunbar of aborta during pralaunch dua to AV» 0C8» or 
Gia> (nodaa 12, 14, .‘^6 raapactivaly) ; aborta dua to no-angina 
atart (node 19); and during a fail^ launcher (node 21) 

11 Indicataa pralaunch check of AV ayatana; if AV not working a 
10 from 103-9 occura, thua replacing 11 by 12 

12 Indieatoa AV not working, 10 occurred in AV aubayaCaa 103-9 

Arc 12-15: update l-«in back counter (-2) 

Arc 12-17: update S^in front counter (-5) 

Arc 12-6: ahowa CCS atill functioning 

Arc 12-3: atarta r«K>val and replacement of AV 

13 Indicatea whether ground equipment (GBMa and RCT) ia working — 
if not, IS occura from arc 93-96, output of node 13 ia 
replaced by node 14 

Arc 13-16: grouiul equipment working, continue prelaunch check 

14 Indicates ground equipment failure (cauaed by 13 from arc 95-96) , 
stopa pralaunch for repairs 

Arc 14-17: update S-mln front counter (-5) 

Arc 14-13: update l-mln back counter (-2) 

Arc 14-7: removal pulse to node 7, where node 7/8 releases 

pulse when ground equipment is repaired 

16 Indicates whether CCS is working — if not, 30 from arc 143-144 
replaces output of 16 with output of 26 
Arc 16-17: indicates CCS working, updates node 17 and 

decreases 5 to 4, then 4 to 3, etc. (This 
is how 5 min are counted. If prelaunch time 
is changed to 10 min, then replace N1 and N2 of 
node 17 with 10) 

Arc 16-13: l-mln loop back occurring 3 times resulta in 

3 min for prelaunch node 13 at 1 (due to 11); 
at 0, node releases and prelaunch starts again 

26 Indicates CCS failure (caused by 30 from arc 143-144); pre- 
launch stopped for repairs which puts node 26 with 16 
Arc 26-17: update S-min front counter (-5) 

Arc 26-15: update 1-min back counter (-2) 

Arc 26-7: CCS failure, waits at 7 until CCS repaired 

(actually, 7 moves to 178, but model waits 
at 179, continues check until GC8 la ready) 
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Mod< Significance 

15 Indicates reset .>f 1-min counter if prelaunch aborted by 12 » 

14 » 26 » or 17 (when released) 

Arc lS-11: start prelaunch again 

17 Indicates the number of 1-min checks that have been made (if 
prelaunch becomes 10 min, change N1 and N2 to 10) 

Arc 17-18: prelaunch acceptable» attempt to start engine 

Arc 17-15: update 1-min counter to stop 

Indicates another prelaunch check — If another Item needs to be 
checked during prelaunch, follow same format; arc 13-16 Includes 
possibility for failure as represented by dotted lines, and must 
have repair status like GCS ^ . Also, 

1) Update 17 with -5 

2) Update 15 with -2 

3) Divert to 7 to create failure sli&llar to GCS 

4) Place operating up and down between Arc 7-178 

18 Indicates engine start, a probabllstlc node In that the engine 
may or may not work 

Arc 18-20: the probability of the engine working .999 defined on arc 

Arc 18-19: the probability of the engine not working .001 defined 

on arc 

19 Indicates engine did not start, AV failed on launcher 

Arc 19-3: start abort and replacement of AV 

20 Indicates engine working, the command Is given for the launch of AV 

Arc 20-21: launcher failed .001, needs 15-min to repair 

Arc 20-22: launcher worked, AV In air, .999, mission flight has begun 

21 Indicates launcher failed but has been fixed now due to the 15 min 
along arc 20-21 

Arc 21-9: count as abort so that another prelaunch can begin 

22 Indicates launcher worked, AV In air and mission flight has begun 

Arc 22-4: start the 15 min needed to prepare another AV on the 

launcher 

Arc 22-23: 1-min time no signal, just sending pulse to climbout 

23 Indicates AV is up and working (similar to prelaunch node 11) 

Arc 23-24: AV has failed somewhere 

Arc 23-25: Update arc for the 5-mln climbout 

Arc 23-27: AV OK, continue to check other components 


Wo4« Slanlflctnc* 

24 Indicates AV fallura* AV will crash or an MP fallad and will ba 
takan up In 154 

Arc 24-29 t updata S-mln countar (-5) 

Arc 24-25: updata l-mln countar (-2) 

Arc 24-71: failure of mission flight 

25 (saa 36) 

Arc 25-23 

27 Indicates grovmd equipment system check 

Arc 27-28: failure 

Arc 27-37: ground equipment 0K» continue 

28 Indicates ground equipment failure 

Arc 28-29: update 5-mln counter (-5) 

Arc 28-25: update 1-mln counter (-2) 

Arc 28-71: failure of mission flight, AV lost 

29 Indicates the number of I -min checks that have bean made; If 
necessary to change cllmbout to 10 min, changes N1 and N2 of 
mode 29 to 10. 

Arc 29-30: cllmbout OK, all systems good for 5 min 

Arc 29-25: updates 1-mln counter (node 25) to stop 

37 Indicates loss of AV control through CCS passing arcs 137 to 139, 
resulting In the loss of an AV 
Arc 37-45: If via arc 137-139, CCS down 

Arc 37-58: CCS OK, continue 

45 Indicates GCS failure t y} the point at which control of un AV 

cannot be maintained, [^] occurs where flight Is stopped, AV lost 
Arc 45-37: resets node back upon starting a prelaunch 

Arc 45-29: updates 5-raln counter (-5) 

Arc 45-25: updates I -min counter (-2) 

Arc 45-71: stops flight and exits 

58 Indicates whether GG8 passed arc 138-140 which means GCS cannot 
perform a flight, but control of AV is still good anough to 
attempt a recovery 

Are 58-68: done by arc 138-140 GCS duwn/start recovery 

Arc 58-29: update 5-min counter 

Arc 58-25: ready to begin next 1-mtn check; distribution 1, 

parameter I 

68 Indicates GCS failure, but control of AV Is still possible, then ^ 
occurs, then exit baseline model and recover 
Arc 68-58: GCS OK, reset 

Arc 68-29: update 5-min counter 
Arc 68-25: update l-min counter 
Arc 68-165: start recovery part of flight 
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Node 


Signiflcence 


30 Indlcetee beginning of outbound eye tern check » etertlng with operetlon 
of AV eubeyeteme 

Arc 30-31: AV eubeystem failed, exit via ^ 

Arc 30-32: AV eubayatema OK, continue 

Arc 30-36: update 1-mln counter to ready 


OUTBOUND, MISSION (Figure 7) 


31 Indicates AV subsystem failure; from 103 to 108 and 109 if MP is 
Included in dataset 

Arc 31-30: flight over, reset 

Arc 31-39: update 20-mln counter 

Arc 31-71: stop flight, mission flight failure due to AV subsystem 

Arc 31-36; update 1-mln counter to stop 

32 Indicates ground-equipment system check 

Arc 32-33: done by ^ showing failure 

Arc 32-75: ground equipment OK, continue 

33 Indicates ground equipment failure 

Arc 33-32: ground equipment fixed via 0 

Arc 33-39: update 20-mln counter (-20) 

Arc 33-71: mission flight failure, AV lost 

Arc 33-36: update 1-mln counter to stop 

75 (see 37) 

Arc 75-76: caused by arc 137-139, GCS down 

Arc 75-77: GCS OK, continue 

76 (see A5) 

Arc 76-73: resets GCS back to working status upon prelaunch 

Arc 76-71: stops flight and exits 

Arc 76-36: updates 1-mln counter to stop 

Arc 76-39: updates 20-min counter (-20) 

77 (see 58) 

Arc 77-78: done by arc 138-140, GCS down/start recovery 

Arc 77-34: GCS OK, continue 

78 (see 68) 

Arc 78-77: GCS OK, reset arc to prelaunch 

Arc 78-39: update 20-mln counter 

Arc 78-36: update 1-mln counter 

Arc 78-154: start recovery part of flight 
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34 Indicates environmental check for the poasibllity of being shot dawn 
Arc 34-38: AV survived .999 on arc 
Arc 34-35: AV shotdown .001 on arc 


35 Indicates AV shot down-lost 

Arc 35-39: update 20-mln counter (-20) 

Arc 35-71: mission flight failure* AV lost 

Arc 35-36: update 1-min counter to stop 

38 Indicates AV survived /split node from probability node 

Arc 38-36: ready to begin next 1-mln check; distribution 1, 

parameter 1 

Arc 38-39: update 20-mln counter (1) 

36 Indicates start of 1-mln counter which sequences the checks 

Arc 36-30: start check again 

39 Indicates the muid>er of 1-mln checks that have been made 

Arc 39-40: outbound flight good, continue 1 min distribution 1, 

parameter 1 

Arc 39-36: stop 1-mln counter, reset (-1) 

Arc 39-36: stop 1-min counter (-1, 1 min) 

40 Indicates beginning of mission system check and check of 
AV subsystems 

Arc 40-41: AV subsystem failed, exit via flo] 

Arc 40-44: update 1-min counter to ready 

Arc 40-42: AV subsystems OK, continue 

41 Indicates AV subsystem failure; from 103 to 108 and 109 if MP 
included in dataset 

Arc 41-40: flight over, reset 

Arc 41-49: update 120-min counter (two-60* s) 

Arc 41-44: update 1-min counter to stop 

Arc 41-71: mission flight failure 

42 Indicates ground equipment system check 

Arc 42-43: done by ^ failure 

Arc 42-79: ground equipment OK, continue 

43 Indicates ground equipment failure 

Arc 43-42: ground equipment fixed via ^ 

Arc 43-49; update 120-min counter (two-60's) 

Arc 43-44: update 1-mln counter to stop 

Arc 43-71: mission flight failure 

44 Indicates start of 1-min counter which sequences the checks 

Arc 44-40: start check again 
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Hoda 


Slanlflcanc* 


79 (see 37) 

Arc 79-145: ceused by arc 137-139, GCS down 

Arc 79-146: GCS OR, continue 


145 


(see 45) 
Arc 145-79: 
Arc 145-49: 
Arc 145-71: 
Arc 145-44: 


resets node back upon starting a prelaunch 
updates 120-min counter (two-60's) 
stops mission and exits 
updates 1-min counter (-2) 


146 (see 58) 

Arc 146-147: caused by arc 138-140, GCS down/start recovery 
Arc 146-46: GCS OK, continue 


147 


(see 68) 

Arc 147-146: 
Arc 147-154: 
Arc 147-49: 
Arc 147-44: 


GCS OK, reset 

start inbound and recovery of AV 
update 120-min counter 
update 1-mln counter 


46 Indicates environmental check for the possibility of being shot down 

Arc 46-47: AV shot down (.001 on arc) 

Arc 46-48: AV survived (.999 on arc) 

47 Indicates AV shot down — lost 

Arc 47-49: update 20-mln counter (-120) 

Arc 47-71: mission flight failure, AV lost 

Arc 47-44: update 1-mln counter (-2) to stop 

48 Indicates AV survlved/spllt node from probability node 

Arc 48-49: update 120-min counter (1) 

Arc 48-44: ready to begin next 1 min 

49 Indicates the number of 1-mln checks made during the mission 

Arc 49-50: mission good, continue with inboxmd 1 min fs] 

distribution 1, parameter 1 
Arc 49-49: stop 1-min counter reset (-1) 

Arc 49-44: stop 1-mln counter reset (-1, 1 min) 


50 Indicates how many times the RPV passed the mission (statistics node) 
Arc 50-53: send pulse on 

51/52 Indicates the number of "sets of three" of completed missions 
(both nodes do the same Job) 
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INBOUND. RECOVERY (Figure 8) 


Node Significance 

53 Indicates beginning of Inbound systems check, starting with 
operation of AV subsystems 

Arc 53-54: AV subsystem failed, exit via @ 

Arc 53-56: AV subsystem OK. continue 

Arc 53-57: update 1-mln counter 

54 Indicates subsystem failure from 103 to 108 and 109 If MP Is 
Incliided In dataset 

Arc 54-53: flight over, reset 

Arc 54-62: update 2S-min counter (-25) 

Arc 54-57: update 1-mln counter to stop 

Arc 54-71: stop flight, mission flight failure due to AV subsystem 

56 Indicates ground equipment system check 

Arc 56-55: done by ^ failure 

Arc 56-148: ground equipment OK, continue 

55 Indicates equipment failure 

Arc 55-56: ground equipment fixed via y 

Arc 55-62: update 25-rain counter (-25) 

Arc 55-57: update 1-mln counter to stop 

Arc 55-71: mission flight failure, AV lost 

148 Indicates loss of AV control through GCS passing arcs 137-139. 
resulting in the loss of an AV 

Arc 148-149: GCS down done by arc 137-139 
Arc 149-59: GCS OK, continue 

149 Indicates GCS failure to the point at which control of an AV cannot 
be maintained ^ occurs where flight is stopped, AV lost 

Arc 149-148: resets node back upon starting a prelaunch 
Arc 149-62: updates 25-mln counter (-25) 

Arc 149-57: updates 1-min counter to stop 

Arc 149-71: stops flight, AV lost, and exit 

59 Indicates environmental check for the possibility of being shot down 

Arc 59-60: AV shot down (.001 on arc) 

Arc 59-61: AV survived (.999 on arc) 

60 Indicates AV shot down, lost 

Arc 60-62: update 25-min counter 

Arc 60-71: mission flight failure, AV lost 

Arc 60-57: update 1-min counter to stop 
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Hod* Stanlflcanct 

61 Indicates AV survived /split node from probability iu>de 

Arc 61-62: update 20-min counter 

Arc 61-57: ready to begin next 1-min check; distribution 1» 

parameter 1 

57 Indicates start of 1-min counter which sequences the checks 
Arc 57-53: start check again 

62 Indicates the number of 1-min checks that will be made. (If 
necessary, inbound can be changed, for example, from 25 to 30. 
simply by replacing N1 and N2 with 30 in node 62) 

Arc 62-63: inbound flight good, continue 1 min; distribution 1. 

parameter 1 

Arc 62-57: stop 1-min counter reset (-1) 

Arc 62-57: stop 1-mln counter reset (-1, 1 min) 

63 Indicates beginning of recovery, checking of AV subsystems 

Arc 63-6A: AV subsystem failed, exit via ^ 

Arc 63-66: AV subsystem OK. continue 

Arc 63-67: update 1-mln counter to ready 

64 Indicates AV subsystem failure from 103 to 108 and 109 if MP Included 
in dataset 

Arc 64-63; flight over, reset 

Arc 64-69: update 10-min recovery counter 

Arc 64-67: update 1-mln recovery counter to stop 

Arc 64-71: mission flight failure , 


66 Indicates ground equipment system check 
Arc 66-65: done by ^ failure 

Arc 66-150: ground equipment OK, continue 


65 Indicates ground equipment failure 


Arc 65-66 
Arc 65-71 
Arc 65-69 
Arc 65-67 


ground equipment fixed via E3 
mission flight failure 
update iG-min counter (-10) 
update 1-mln counter to stop 


151 Indicates CCS failure to the point at which control of AV cannot be 
maintained occurs where flight Is stopped. AV lost 

Arc 151-150: resets node back upon starting » prelaunch fTI 
Arc 151-67: updates 1-min counter to stop 

Arc 151-69: updates 10-min counter (-10) 

Arc 151-71: stops flight, AV lost, and exit 


67 Indicates start of 1-mln counter which sequences the checks 
Arc 67-63: starts check again 
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69 Indicates the number of 1-mln checks during the recovery that have 
been made 

Arc 69-70: recovery good (till net), continue with probability 

of net working 

Arc 69-69: stop 1-mln counter reset (-1) 

Arc 69-67: stop 1-mln counter reset (-1, 1 min) 

70 Indicates the probability that recovery net works 

Arc 70-72: net work good, AV recovered (.99) 

Arc 70-71: net failed, AV lost (.01) 


RECOVERY, TIMER (Figure 9) 


71 Indicates mission flight failure; AV lost; however, if MP failed, 
then mission is not considered a failure 

289 Indicates whether failure occurred In MP 
Arc 289-288: if failure In MP. hold 
Arc 289-152: failure not In MP; AV lost, reset 

288 Indicates pulse stopped; MP failed but AV In recovery mode; pulse 
reestablished from subrecovery mode 
Arc 288-289: reset 

/ 

72 Indicates mission flight successful; no problems disrupted the baseline 
program; mission counts as one good 3-hr sortie 

Arc 72-73: update 3-sortle counter 

Arc 72-153: update CCS available 

Arc 72-7A: put AV back In pool 

73 Indicates the number of days In which three 3-hr sorties were 
completed successfully 

Arc 73-102: ^ stop 12-hr clock; three mission flights have been 

completed within the time period 

74 Indicates AV replacement Into pool 

Arc 74-5: where 5 Is pool, -1 to add to counter 

152 Indicates CCS checked for readiness 

Arc 152-153: stop and hold until CCS Is fixed 
Arc 152-6: GCS available, start prelaunch again 

153 Indicates system holding until GCS Is ready 
Arc 153-152: GCS Is ready, return 

Arc 152-152: l-mln loop. Checks status of GCS every 1 min 
(helps prevent Infinite loops) 
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101 Indicate* start of 12-hr clock at beginning of alnalatlon; If clock 
run* out before conpletlon of three good aortlea (Are 73-102) i 
slmulatlcn la terminated (end of daylight hra) 

Arc 101-102: 12 hr have pasaed 

102 Indicate* pulse received for completion of three mission flights or for 
completion of 12-hr period 

Arc 102-180: three sorties completed first 
Arc 102-181: 12 hrs have passed 

180 Indicates three mission flights were completed, 12-hr clock starts 
again and records In N229 

Arc 180-101: starts 12-hr clock for next day, model starts prelaunch 
automatically with Arc 152-6 
Arc 180-299: decrease 299 by one 

299 Indicates maximum of 10 successful days, then stops simulation run 
Arc 299: sink node 

181 Indicates three sorties were not completed within 12 hrs; 12 hr 
arrived at 102 first and diverted to 181 

Arc 181-182: send pulse to stop simulation 

182 Indicates 12 hrs over before three mission flights, collect statistics 

Arc 182: sink node 


AV SUBSYSTEM (Figure 10) 


80 


Indicates beginning 
Arc 80-103: starts 
Arc 80-104: starts 
Arc 80-105: starts 
Arc 80-106: starts 
Arc 80-107: starts 
Arc 80-108: starts 
Arc 80-109: starts 


of simulation; starts all components of AV 

FCEP distribution 

ARA distribution 

ADT distribution 

electric power distribution 

airframe distribution 

prop distribution 

mission payload distribution 


103 Indicates beginning of distribution for FCEP 

Arc 103-81: distribution 4, parameter 9, number 10 


104 Indicates beginning of distribution for ARA 

Arc 104-81: distribution 4, parameter 10, number 10 

105 Indicates beginning of distribution for ADT 

Arc 105-81: distribution 4, parameter 11, number 10 
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Mod« Signiflcanc* 

106 IndlcatM beginning of distribution for electric power 
Arc lC6-81t distribution persmeter 12, mntber 10 

107 Indlcetes beginning of distribution for the slrfreme 

Arc 107-81: distribution 4, persneter 13, number 10 

108 Indlcetes beginning of distribution for the prop 

Arc 108-81: distribution 4, parameter 14, number 10 

109 Indicates beginning of distribution for the MP 

Arc 109-183: distribution 4. parameter 4, number 11 

183 Indicates failure of mission payload 

Arc 183-81: failure occurred in mission payload during prelaunch 

check 

Arc 183-184: node exchange done after prelaunch Q] 

81 Indicates failure in an AV subsystem (from 103 to 108 and 183) 
or distributions stop and restart; by 2 (the H denotes the halt 
command specified in GRASP in which one pulse is received, and 
the others are Ignored) 

Arc 81-82: hold pulse until prelaunch is ready again 

Arc 81-80: start a new set of AV distribution for an AV on 

the latincher 

82 Indicates pulse is postponed until prelaunch is ready 

Arc 82-82: return pulse 

Arc 82-81: return pulse to node 81 to start A 

184 Indicates failure of mission payload after prelaunch before 
mission return of AV 

Arc 184-183: reset node back before prelaunch 

Arc 184-186: failure occurred, start recovery 

185 Indicates failure of mission payload during mission return of AV 
via an inbound flight 

Arc 185-186: reset back with Q] 

Arc 185-154: send pulse to auxiliary recovery - Inbound 

186 Indicates failure of mission payload during climbout and outbound flight 

Arc 186-165: send pulse to auxiliary recovery 

Arc 186-185: divert pulse to auxiliary recovery on Inbound if 

mission payload fails 
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CROUMD iqUlFMBNT (Figure 10) 


Node Significance 

85 Ittdicecea beginning of eimulation 

Arc 85-86: start* RGT failure distribution; distribution A, 

parameter 3 

Arc 85-93: updates ground equipment status 

Arc 85-95: update ground equipment status 

86 Indicates failure of RGT 

Arc 86-93: update ground equipment status 

Arc 86-95: update ground equipment atatus 

Arc 86-85: repair of RGT; distribution 1, parameter ? 

87 Indicates beginning of simulation 

Arc 87-88: starts generator failure distribution; 

distribution 4, parameter 6 
Arc 87-89: updates ground equipment atatus 

Arc 87-92: updates ground equipment status 

88 Indicates failure of generator 1 

Arc 88-87: repair of generator 1; distribution 1, parameter 7 

Arc 88-89: update ground equipment status 

Arc 88-92: update ground equipment status 

89 Indicates whether one of two generators is working 

Arc 89-93: update arc 

Arc 89-95: update arc 

Arc 89-92: update arc 

90 Indicates beginning of simulation 

Arc 90-91: starts generator failure distribution 

Arc 90-89: update ground equipment status 

Arc 90-92: update ground equipment status 

• 91 Indicates failure of generator 2 

Arc 91-90: repair of generator 2; dirtrihutlon 1. parameter 7 

Arc 91-92: update ground equipment stat'is 

Arc 91-89: update ground equipment status 

92 Indicates whether or not both generators are working 

Arc 92-95: update arc 

Arc 92-93: update arc 

Arc 92-89: update arc 

93 Indicates CCS status (update node) 

Arc 93-95: update arc 

Arc 93-94: arc for ground equipment status up 

94 lndicac<;8 ground equipment working 
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95 Indicates GC8 status (update node) 

Arc 9S-93I update arc 

Arc 95-96: arc for ground equlpnent atatua doim Qj 

96 Indicates ground equipment not working 


GROUND CONTROL STATION (Figure 11) 


110 Indicates beginning of GCS aubsyaten distributions 

Arc 110-111: starts the GCSIU distribution 

Arc 110-115: starts the AVOC console distribution 

Arc 110-119: starts the MP console dl itribution 
Arc 110-123: starts the MC console distribution 
Arc 110-127: starts the NDU distribution 

Arc 110-131: starts the main computer distribution 

Arc 110-5: subtracts one AV from the AV-ready pool when one 

AV is on launcher at start of simulation — this 
is easier than any other method 

111 Indicates beginning of GCSIU distribution 

Arc 111-112: GCSIU parameter set 15, distribution 4 

Arc 111-141: updater arc for GCS up (141-142) 

Arc 111-143: updater arc for GCS down (143-144) 

112 Indicates GCSIU failure 

Arc 112-111: start repair; parameter 21, distribution 1, nuoiber Q 

Arc 112-141: updater arc for GCS repaired 

Arc 112-143: updater arc for GCS down 

Arc 112-113: timed check to see if GCSIU can be repaired before 

fail is scheduled; distribution 1, parameter set 27 

113 Indicates available time for on-site repair has passed and obsein^ed 
vehicle must be scheduled for repair — GCSIU 

Arc 113-114: repair did not take place within check time schedule 

failure 

Arc 113-114: divert pulse to stop ^ 

Repair has taken place within the check time 

114 Indicates pulse stopped, failure of GCSIU 

Arc 114-113: reset back ^ 

115 Indicates beginning of AVOC distribrition 

Arc 115-116: AVOC parameter set 16, distribution 4 

Arc 115-141: updater arc for GCS up (141-142) 

Arc 115-143: updater arc for CCS down (143-144) 

Arc 115-135: updater for two console failure 
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116 ZadieatM AVOC f«ilur« 

Arc 116-115: start rapalr parasMtar aat 22 • diatrlbution 1 
116-141: updater arc for GC8 repaired 
Arc 116-142: updater arc for GC8 down 

Arc 116-117: tlnad check to see If AVOC can be repaired before 

failings parameter aat 27, dietribution 1 

117 Indicates available time for on-site repair has passed and 
observed vehicle must be scheduled for repair — AVCC 

Arc 117-135: repair did not take place within check tlJM; 

schedule failure 

Arc in-llb: repair did not take place within check time; 

schedule failure 

Arc 117-118: divert pulse to stop 

118 liulicates pulse stopped due to failure of AVOC 

Arc 118-117: reset back 

119 Indicates beginning of MPC distribution 

Arc 119-120: MPC parameter set 17, distribution 4 

Arc 119-141: updater arc for CCS up (141-142) 

Arc 119-143: updater arc for CCS down (143-144) 

Arc 119-135: updater for two console failure 

120 Indicates MPC failure 

Arc 120-119: start repair parameter set 23 » distribution 1 

Arc 120-141: updater arc for CCS repaired 

Arc 120-142: updater arc for CCS down 

Arc 120-121: timed check to see if MPC can be repaired before 

failing parameter set 27, distribution 1 

121 Indicates available time for on-site repair has passed and observed 
vehicle must be scheduled for repair — MPC 

Arc 121-135: repair did not take place within check time failure 

scheduled 

Arc 121-136: repair did not take place within check time failure 

scheduled 

Arc 121-122: divert pulse to stop ^ 

122 Indicates pulse stopped for failure of MPC 

Arc 122-121: reset back ^ 

123 Indicates beginning of MCC distribution 

Arc 123-124: MFC parameter set 18, distribution 4 

Arc 123-141: updater arc for CCS up (141-142) 

Arc 123-143: updater arc for CCS down (143-144) 

Arc 123-135: updater for two console failures 
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124 liidlCAtM HCC failurt 

Arc 124-1231 start repair paranatar sat 24 » diatributloii 1 
Are 124-141: updatar are for CCS rapairad 
Arc 124-143: :^atar are for CCS down 

Arc 124-123: tliMid chock to aaa If MCC can ba rapairad bafora falling 
paranatar oat 27, distribution 1 

125 Indicatoo tiiM over — MCC 

Arc 123-133: repair did not taka place within check tine 

failure schedule 

Arc 123-136: repair did not take place within check tim 

failure schedule 

Arc 123-126: divert pulse to stop gj 

126 Indicates pulse stopped for failure of MCC 

Arc 126-125: reset back ^ 

127 Indicates beginning of NDU distribution 

Arc 127-129: NDU parameter set 19, distribution 4 

Arc 127-141: updater arc for CCS up (141-142) 

Arc 127-143: updater arc for CCS down (143-144) 

12& Indicates NDU failure 

Arc 128-127: start repair parameter set 25, distribution 1 

Arc 128-141: updater arc for CCS repaired 

Arc 128-143: updater arc for CCS down 

Arc 128-129: timed check to see if NDU can be repaired before 

failing; parameter set 27, distribution 1 

129 Indicates time over — NDU 

Arc 129-138: repair did not take place within check time 

recovery scheduled 

Arc 129-130: divert pulse to stop @ 

130 Indicates pulse stopped for NDU failure 

Arc 130-129: reset back Q 

131 Indicates beginning of main computer distribution 

Arc 131-132: main computer parameter set 20, distribution 4 

Arc 131 141: updater arc for CCS up (141-142) 

Arc 131-143: updater arc for CCS down (143-144) 

132 Indicates main computer failure 

Arc 132-131: start repair; parameter set 26, distribution 1 

Arc 132-141: updater arc for CCS repaired 

Arc 132-143: updater arc for CCS down 

Arc 132-133: timed check to see if laaln computer can be repaired 

before failing; distribution 1, parameter set 27 
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Mode Slanlflcence 

133 Indicates time over — main computer 

Arc 133-138: repair did not take place within check time 

recovery scheduled 

Arc 133-134: divert pulse to stop m 

134 Indlcauea pulse stopped due to failure of main computer 

Arc 134-133: reset back ^ 

135''<> Indicates failure of two consoles 

Arc 135-137: failure of GCS — If AV is In the air. It's lost 

136* Indicates i.lure of one console 

Arc 136- I 3b; st rt recovery operations 

137 Indicates GCS failure, loss of AV 

Arc 137-139: failure of GCS scheduled a for the main model 

Arc 137-176: guard — protect from having two pulses issued along 

arc 137-139 for a mission flight 

139 Indicates loss of AV 

176 Indicates pulse stopped; only one pulse needed 

Arc 176-137: reset by 

138 Indicates failure of GCS, AV returned for recovery 

Arc 138-140: failure of GCS schedule a ^ for the main model 

140 Indicates beginning of recovery 

177 Indicates pulse stopped -* only one pulse needed 

141 Indicates GCS repaired 

Arc 141-142: schedule ^ for main model 

Arc 141-143: (5) GCS repaired, update 

142 Indicates GCS repaired 

143 Indicates GCS not working 

Arc 143-144: GCS down, schedule ^ for main model 

Arc 143-141: GCS down, update 

144 Indicates GCS not working 


*The three-console model here should be redesigned so that three dis- 
tributions (or as many as necessary) could be altered to indicate loss of 
AV control to the extent that (1) the mission would be aborted and the AV 
recovered or (2) recovery would be impossible and the AV lost. 
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AUXILIARY RECOVERY (Figure 12) 


Node SlRnlflcanco 

154 Indicates beginning of auxiliary inbound ayatem check* atarting %d.th 
all AV aubayatema 

Arc 154-1S5: AV aubayatem failed, exit via §3 

Arc 154-156: AV aubayatem continue 
Arc 154-163: update 1-mln counter 

155 Indicates AV subsystem failure from 103 to 108 and 109 if NP is 
included in dataset 

Arc 155-154: flight over, reset 

Arc 155-164: updater for 25-min counter 

Arc 155-175: mission flight failure, AV lost 

Arc 155-163: updater for l-min counter 

156 Indicates ground equipment system check 

Arc 156-157: done failure 

Arc 156-158; ground equipment OK, continue 

157 Indicates ground equipment failure 

Arc 157-156: ground equipment fixed via 0 

Arc 157-164: updater for 25-min counter 

Arc 157-175: mission flight failure, AV lost 

Arc 157-163: updater for l-min counter 

158 Indicates loss of AV control through arc 137-139, resulting in 
loss of AV 

Arc 158-159: AV lost 

Arc 137-139: GCS inoperative 

Arc 158-160: GCS operating, continue mission 

159 Indicates GCS failure to the point at which control of an AV cannot 
be maintained ^ occurs where flight is stopped and AV lost 

Arc 159-158: reset node back upon starting a prelaunch 

Arc 159-175: stops flight, AV lost, and exit 

Arc 159-164: updates 25-min counter 

Arc 159-163: updates l-min counter 

160 Indicates environmental check for the possibility of being shot down 

Arc 160-162: AV survived (.999 on arc) 

Arc 160-161; AV shot dowi^ (.001 on arc) 

162 Indicates AV survived/spl it node from probability node 
Arc 162-164: update 20-min counter 

Arc 162-163: ready to begin next l-min check; distribution 1, 

parameter set 1 
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Mode 


Significance 


161 Indlcetee AV shot down — lost 

Arc 161>164: update 25-mln counter 

Arc 161-163: update 1-mln counter 

Arc 161-175: mission flight failure, AV lost 

163 Indicates start of 1-mln coxmter which sequences the checks 

Arc 163-154: start check again 

164 Indicates the number of 1-mln checks that have been made. 

Arc 164-163: stop 1-mln counter, reset (-1) 

Arc 164-163: stop 1-mln counter, reset (-1, 1 min) 

Arc 164-165: inbound flight good, continue 

165 Indicates beginning of recovery, checking of AV subsystem 

Arc 165-166: AV subsystem failed, exit via 0 

Arc 163-161: update 1-tnln counter to ready 

Arc 163-167: AV subsystem OK, continue 

166 Indicates AV subsystem failure from 103 to 108 and 109 If MP 
included in dataset 

Arc 166-165: flight over, reset 

Arc 166-172: update l0-m<n recovery counter 

Arc 166-171: update 1-min recovery counter to stop 

Arc 166-175: mission flight failure 

167 Indicates CCS failure to the point at which control of an AV cannot 
be maintained ^ occurs 

Arc 167-168: resets node back upon starting a prelaunch m 

Arc 167-169; GCS OK, continue 

168 Indicates GCS failure, AV lost 

Arc 168-172: update 10-min recovery counter 

Arc 168-171: update 1-min counter 

Arc 168-173: mission flight failure, AV lost 

169 Indicates ground equipment system check 
Arc 169-170; done by ^ failure 

Arc 169-172: ground equipment working, continue 

170 Indicates ground equipment failure 

Arc 170-169: ground equipment fixed via 0 

Arc 170-172: update 10-min counter 

Arc 170-171: update 1-min counter to stop 

171 Indicates start of 1-mln counter which sequences the system checks 

Arc 171-163: starts check again 
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Hode 


Significance 


172 Indicates the nuidter of l-adn checks laade during the recovery 

Arc 172-173: recovery good (until net)« continue with 

probability of net 

Arc 172-171: stop 1-mln counter* rest (-1) 

Arc 172-171: stop 1-min counter* reset (-1* 1 min) 

173 Indicates probability that recovery net works 

Arc 173-174: .95 recovery good 

Arc 173-175: .05 recovery bad 

Arc 173-187: node exchange (if HP is bad* probability is lower ES> 

187 Indicates probability that recovery net works without HP for guidance 
Arc 187-190; recovery good .93 
Arc 187-175: recovery bad 

290 Indicates recovery good, HP failvr; 

Arc 290: MS send AV to MS to be repaired 

Arc 290-152: start new mission flight 

174 Indicates recovery good 

Arc 174-5: AV OK, return to ready pool 

Arc 174-152: start new mission flight 

175 Indicates recovery unsuccessful* AV lost 

Arc 175-152: start new mission flight 


MSI lOOZ DIAGNOSTICS (Figure 13) 


200 Indicates initialization of maintenance shelter 1 

Arc 200-201: distribution 1, parameter set 27, installation time 

201 Indicates test of test equipment 

Arc 201-103: test good .99 

Arc 201-202: test not good .01, keys in AVIM 

202 AVIM 

203 Indicates time for fault Isolation to work 

Arc 203-204: parameter set 27, distribution 1, fault isolation 

204 Indicates probability of fault being detected 

Arc 204-206: fault not detected .05 

Arc 204-203: fault detected .95 

205 Indicates probability of repairing the fault with an LRU 

Arc 205-202: cannot be repaired at AVUM (.10) 

Arc 205-207: repaired at AVUM .90 
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Node Slmificence 

206 Indicates that repair may need to take place In GSE» Ldt NEC, GC8« 
or RGT 

Arc 206~210: transfer of pulse 

207 Indicates time to replace LRU 

Arc 207-209: distribution 1. parameter set 27 

209 Indicates service check 

Arc 209-210: service good .999 

Arc 209-201: service not good* start again .001 

210 Indicates service good, send AV back to AV ready pool 

Arc 210-5: AV to ready pool 


MS2 70% CHARACTERISTICS (Figure 13) 


220 Indicates initialization of maintenance shelter 2 

Arc 220-221: distribution 1, parameter set 27 

221 Indicates idle mode 

Arc 221-222: transfer pulse 

222 Indicates fault isolation time 

Arc 222-223: distrlHution I, parameter set 27 

223 Indicates test confirmed from CCS 

Arc 223-224; test not confirmed .^5 

Arc 223-226: test confirmed .95 ' 

224 Indicates check of testing arrangement 

Arc 224-225: test arrangement good .95 

Arc 224-221: test arrangement bad, start again 

225 Send to AVIM 

226 Indicates isolation to LRU 

Arc 226-227: confirmed .90 

Arc 226-225: not possible .10 

227 Indicates AV sent to repair 

Arc 227-228: repair time, distribution 1, parameter set 27 

228 Indicates end of repair 

Arc 228-229: send pulse for service check 
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Node 


Significance 


229 Indlcatee service check 

Arc 229-225: no good, send to AVIM .10 
Arc 229-230: service good .90 

230 Indicates service good* send AV back to ready pool 

Arc 230-5: AV to ready pool 


MS3 CONTRACT SPECIFICATIONS (Figure 13) 


3-188 Indicates Installation time; distribution 1* parameter set 1 

188 Indlcatet^i test for faults 

Arc 188-189: distribution 1, parameter set 7 

189 Indicates probability of problem being fixed 

Arc 189-190: .10, sent to AVIM 

Arc 180-191: .90, send to repair 

190 AVIM 

191 Indicates repair time — send back to ready pool 

Arc 191-5: parameter 8 Q , distribution 1 
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APPENDIX C 


PARAMETER SET 


This section describes the nunbers used for the distributions. The 
distributions use a mean time for failure rate determinstion. Minimum and 
niAviimim time-rates are associated with distributions to provide a means for 
containment of times. 


Distribution Significance 

L Constant 1-min timer; used mostly for 1-min system checks in 

main program 

2 Constant 720-mln (12-hr) timer; used to time 1 day's activities 

Arc 101-102 

3 Exponential distribution on RGT 

10000.0 mean time in minutes 
0.0 minimum time in minutes 

99999999.0 maximum time in minutes 

1.0 puts ERLANG-K into exponential 

4 Mission payload 

10,312 mean time in minutes 

0.0 r.lnlmum time in minutes 

99999999.0 maximum time in minutes 

1.0 puts ERLANG-K into exponential 

5 Old distribution — not used 

6 Generators 

720.000 mean time in minutes 

0.0 minimum time in minutes 

99999999 0 maximum time in minutes 

1.0 puts ERLANG-K into exponential 

7 Constant 30-mln timer 

8 Constant 15-min timer 

9 FCEP 

117,187.5 mean time in minutes 

0.0 minimum time in minutes 

190.0 maximum time in minutes 

1.0 puts ERLANG-K into exponential 


43 


Plitrlbtttion 

10 


11 


12 


13 


14 


15 


16 


17 


Slgnlflcanc* 


ARA 

229665 mean Cine in minutes 
0.0 minimum tine in minutes 
190.0 maximum time in minutes 
1.0 puts ERLANG-K into exponential 

ADT 

267081.34 mean time in minutes 
0.0 minimum time in minutes 
190.0 maximum time In minutes 

1.0 puts ERLANG-’K into exponential 

Electrical power 

180180.18 mean time in minutes 
0.0 minimum time in minutes 
190.0 maxlmiim time in minutes 
1.0 puts ERLANG-K into exponential 


Air frame 

312500.00 mean time in minutes 
0.0 minimum time in minutes 
190.0 maximum time in minutes 
1.0 puts ERLANG-K into exponential 

Propulsion assembly 

48000.0 mean time in minutes 
0.0 minimum time in minutes 
190.0 maximum time in minutes 
1.0 puts ERLANG-K into exponential 

GCS lU 

48000.0 mean time in minutes 
0,0 minimum time in minutes 
99999999.0 maximum time in minutes 

1.0 puts ERLANG-K into exponential 

AVO console 

22779.043 mean time in minutes 
0.0 minimum time in minutes 
99999999.0 maximum time in minutes 

1.0 puts ERLANG-K into exponential 


MPO console 

63492.0635 mean time in minutes 
0.0 minimum time in minutes 
99999999.0 maximum time in minutes 

1.0 puts ERLANG-K into exponential 
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Dlitrlbtttlon 


Slgnificmca 


18 MC console 

57416.2679 mean tine in ndnutaa 
0.0 iBlnlmum time In minutes 

99999999.0 maximum time in minutes 

1.0 puts ERLANG-K into exponential 

19 NDU console 

209790.210 mean time in minutes 
0.0 minimum time in minutes 

99999999.0 maximum time in minutes 

1.0 puts ERLANG-R into exponential 

20 GCS main computer 

157480.0 mean time in minutes 

0.0 minimum time in minutes 

99999999.0 maximum time in minutes 

1.0 puts ERLANG-K into exponential 

21 GCS lU 

15.00 constant repair time 

22 AVO console 

15.00 constant repair time 

23 MPO console 

15.00 constant repair time 

24 MC console 

15.00 constant repair time 

25 NDU console 

15.00 constant repair time 

26 GCS main computer 

15.00 constant repair time 

27 Check time for GCS components 

10.00 constant repair time 
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48 


rellablUty block diagram. 
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Figure 15.- RPV air vehicle subsystem reliability block diagram. 
































APPENDIX D 


ACTIVITY NUMBERS 


Activity numbers are assigned to denote different stages in the simula- 
tion. This section describes these stages and which arcs are used. 


m 

m 

Q 

a 

m 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 


Prelaunch check is about to begin 
Arc :.-ll 

Prelau'ich good/engine start and launch next 
Arc 17-18 

AV has passed outbound ready to begin mission 
Arc 39-40 

AV has passed mission, mission successful 

AV has completed recovery approach, flight over 

AV subsystem component failure 

Mission payload failure 

Ground equipment working 

Ground equipment not working 

Failure of GCS lU 

Reapir of GCS lU 

Failure of AVO conso’«* 

Repair of AVO console 
Failure of MPO console 
Repair of MPO console 
Failure of MC console 
Repair of MC console 
Failure of NAV DPI unit 
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0 

0 

H 3 

HD 

S 


P 

0 


Repair of NAV DPI. unit 

Failure of GCS main computer 

Repair of GCS main computer 

GCS not working 

GCS repaired 

CCS failure - AV lost 

GCS failure — AV in recovery /inbound 

(depends on AV location) 

Successful day completed 

3-3 hr sorties within 12 hours 

Unsuccessful day 

12-hr timer finished 


ACTIVITY Nl^BERS 
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APPENDIX E 


DATA SET DESCRIPTIONS 


Th« followlag CAbl« show! which data aat contains tha aubalammta that 
aupplamant tha GRASP/Amy RPV Slnulatlon MAIN Program. 




















APPENDIX F 


DETERMINATION OF DISTRIBUTIONS 


In this model, Lockheed uses the exponential distribution in all calcula- 
tions. In the GRASP Program this is used as an ERLANG-1 (K * 1), because 
theoretically the exponential distribution is a particular case of the 
ERLANG distribution when K « 1. Thus for the exponential distribution it la: 

Mean (MTBF) - j 

The X*s supplied by Lockheed represent the failure rates per million (10^) 
hours. Therefore, the mean if computed is 1/original X is expressed in 
millions of hours; and 1/X x 10^ is the mean expressed in hours; and 
1/X X ]0^ X 60 is the mean expressed in minutes. This last case is used to 
determine the failure rates since the RPV system model operates in minutes. 


GCS Subsystems 


AVO Console 


X * 2634 


Mean = x 10^ x 60 

which is Parameter Set No. 16 


22779.04 min 


MPO Console 


X = 945 


Mean 


1 

945 


X 10 


X 60 


63492.06 min 


which is Parameter Set No. 17 


Me Console 


X = 1045 


Mean » ^ 10^ x 60 « 57416.27 min 

1045 

which is Parameter Set No. 18 
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NavlRatlon PPL. Console 


286 


Mean « x 10^ v 60 ■ 209790.2 min 


which Is Parameter Set No. 19 


Computer Signal-Processing Unit 
\ - 381 

Mean - "" ^0^ ** " 157480 min 

which Is Parameter Set No. 20 


AV Subsystem 


M ission Payload 
X - 5818 

Mean *■ ^ x 60 » 10312.82 min 

which is Parameter Set No. 4 


FCEP and FLT Sensor Packages 
X - 512 

Mean - x 10^ x 60 » 117187.5 min 
which is Parameter Set No. 9 


ARA 


X - 261 

Mean ■ * lO^ x 60 ■ 229885.06 min 

.101 

which Is Parameter Set No. 10 
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APT 

X - 809 

Mean ■ x 10^ x 60 ■ 74165.64 min 
%fhich Is Parameter Set No. 11 

Baseline Electrical Power 
X - 333 

Mean ■ x 10^ x 60 • 180180.18 min 
which is Parameter Set No. 12 

Air Frame 

X - 192 

Mean - x lO^ x 60 - 312500 min 
which Is Parameter Set No. 13 
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APPENDIX G 


MAINTENANCE SHELTER CONCEPTS (Diagram 8) 


In the GRASP Simulation Program three different types of maintenance 
systems %»ere used to try to describe different typ<»s of diagnostic testing 
techniques . 

Concept 1 ; Options for entire system checkout. Possibility of AV being 
sent to MS In need of repair. 

Concept 2 ; Model from a LMSC document (LMSC-D7 32866) . Purpose: to see 

If GRASP Is a \iseful tool In making direct modeling adaptations. 

Concept 3 : A model resembling a similar contract requirement in which 

90% of the AV's are repaired and returned to service 
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